<!-- This HTML file has been created by texi2html 1.52
from ../vice.texi on 31 August 2002 -->
<TITLE>VICE Manual - 11 The emulator file formats</TITLE>
</HEAD>
<BODY>
Go to the <A HREF="vice_1.html">first</A>, <A HREF="vice_10.html">previous</A>, <A HREF="vice_12.html">next</A>, <A HREF="vice_16.html">last</A> section, <A HREF="vice_toc.html">table of contents</A>.
<P><HR><P>
<H1><A NAME="SEC152" HREF="vice_toc.html#TOC152">11 The emulator file formats</A></H1>
<P>
This chapter gives a technical description of the various files
supported by the emulators.
</P>
<H2><A NAME="SEC153" HREF="vice_toc.html#TOC153">11.1 The T64 tape image format</A></H2>
<P>
(This section was taken from the C64S distribution.)
</P>
<P>
The <CODE>T64</CODE> File Structure was developed by Miha Peternel for use in
the C64S emulator. It is easy to use and allows future extensions.
The speed offset entries can be a little more complex. The 1541 has four
speed zones defined, which means the drive can write data at four
distinct speeds. On a normal 1541 disk, these zones are as follows:
</P>
<TABLE BORDER>
<TR><TD><B>Track Range</B></TD>
<TD><B>Speed Zone</B></TD>
</TR>
<TR><TD>1-17</TD>
<TD>3 (highest writing speed)</TD>
</TR>
<TR><TD>18-24</TD>
<TD>2</TD>
</TR>
<TR><TD>25-30</TD>
<TD>1</TD>
</TR>
<TR><TD>31 and up</TD>
<TD>0 (lowest writing speed)</TD>
</TR></TABLE>
<P>
Note that you can, through custom programming of the 1541, change the
speed zone of any track to something different (change the 3 to a 0) and
write data differently. From the dump of the speed offset entries
above, we see that all the entries are in the range of 0-3. If any entry
is less than 4, this is not considered a speed offset but defines the
whole track to be recorded at that one speed.
</P>
<P>
In the example I had, there were no offsets defined, so no speed zone
dump can be shown. However, I can define what should be there. You
will have a block of data, 1982 bytes long. Each byte is encoded to
represent the speed of 4 bytes in the track offset area, and is broken
down as follows:
</P>
<PRE>
Speed entry $FF: in binary %11111111
|'|'|'|'
| | | |
| | | +- 4'th byte speed (binary 11, 3 dec)
| | +--- 3'rd byte speed (binary 11, 3 dec)
| +----- 2'nd byte speed (binary 11, 3 dec)
+------- 1'st byte speed (binary 11, 3 dec)
</PRE>
<P>
It was very smart thinking to allow for two speed zone settings, one in
the offset block and another defining the speed on a per-byte basis. If
you are working with a normal disk, where each track is one constant
speed, then you don't need the extra blocks of information hanging
around the image, wasting space.
</P>
<P>
What may not be obvious is the flexibility of this format to add tracks
and speed offset zones at will. If a program decides to write a track
out with varying speeds, and no speed offset exist, a new block will be
created by appending it to the end of the image, and the offset pointer
for that track set to point to the new block. If a track has no offset
yet, meaning it doesn't exist (like a half-track), and one needs to be
added, the same procedure applies. The location of the actual track or
speed zone data is not important, meaning they do not have to be in any
particular order since they are all referenced by the offsets at the
beginning of the image.
</P>
<P><HR><P>
Go to the <A HREF="vice_1.html">first</A>, <A HREF="vice_10.html">previous</A>, <A HREF="vice_12.html">next</A>, <A HREF="vice_16.html">last</A> section, <A HREF="vice_toc.html">table of contents</A>.
